ci: publish released MWS images to GHCR - #137
Conversation
There was a problem hiding this comment.
Pull request overview
This PR updates the container build and CI/CD so MultiWikiServer images are produced from published releases (or a manual dispatch) and pushed to GHCR with only an immutable @tiddlywiki/mws version tag (no main/latest).
Changes:
- Docker image now installs a single exact
@tiddlywiki/mwsversion (viaMWS_VERSIONbuild arg) and runsmws update-tiddlywikiat build time, matching thenpm init @tiddlywiki/mwsinstance template. - Adds a GitHub Actions workflow that builds on PRs (no publish) and publishes on GitHub Release
publishedevents (or manual dispatch) after verifying the npm version exists.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
Dockerfile |
Pins the installed @tiddlywiki/mws version via build arg, aligns instance-data format with the template, and runs mws update-tiddlywiki during image build. |
.github/workflows/publish-container.yml |
Introduces PR build + release/manual publish workflow to GHCR using an immutable version tag. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| - name: Check out release source | ||
| uses: actions/checkout@v4 | ||
| with: | ||
| ref: ${{ github.event.release.tag_name || github.sha }} | ||
|
|
|
I'm creating my own GitHub workflow and Dockerfile based on the discussions here and in #129. Please refer to that issue for further updates. |
|
Okay, looking forward to it. Just remember, don't mix app code and data in the base image. NodeBB image, as an example, have this problem, and will become a real mess to manage, when upgrading its base image, all installed plugins and plugin config will be lost, because they reside in |
|
MWS can already be global installed ( Plugins are an interesting case. MWS doesn't have plugins currently, but I'll keep that in mind if I ever do. |
Replaces #134 with a release-based container workflow.
This does not build production images from
mainand does not install@latest:npm init @tiddlywiki/mws: it uses the0.2.0instance-data format, installs one exact published@tiddlywiki/mwsversion, and runsmws update-tiddlywikiwhile building the image.npm installruns, so an Alpine build can compile a dependency when a prebuilt binary is unavailable.ghcr.io/tiddlywiki/multiwikiserver:0.2.4; the workflow deliberately does not publishmainorlatest.The existing Docker Compose volume contract is unchanged: only
/data/storeis mounted. This PR does not impose my Kubernetes-specific full-/datalayout.